A ‘log file’ typically records events that occur in a computer system. Some example events include “call”, “execute”, “open”, “close”, “wait”, “fetch”, “sort”, “append”, “run”, and “delete”. A code trace or ‘trace’ comprises a text listing of events in chronological order in which the events occur in a computer system. A ‘trace log file’ comprises a log file in which a trace is recorded as computer program code executes within a computer system. A trace log file may contain time information indicative of the time of occurrence of events recorded within the trace. A trace log file, therefore, reports transformations of computer system configuration to process different computer program instructions over some time frame.
In general, a trace includes information on source code but not the source code itself, e.g. if the source code is ‘CALL METHOD ABC’, this may be seen as ‘CALL METHOD ABC’ in the trace, for example. However, a source code line such as ‘A=A+1’ will not be recorded at all and may be accounted to the parent event as its net time, for example. However, the trace can in fact record information about the source code because in the mode of tracing the source code may not be complied completely or the execution of complied code can be linked back to the source code by means of debug information and source code addresses.
A call trace includes text that is representative of ‘calls’. A call is a request by one computer program or process for service from another program or process. It is not unusual for a program or process to spawn a hierarchy of calls in which a called program calls another program and that other program calls yet another program, for example. Calls and call hierarchies often are recorded within trace log files. A trace log file contains much explicit time related information such as call level, gross time and net time for an event.
FIGS. 1A-1B are illustrative drawings showing call level relationships and time durations of a hierarchy of calls (FIG. 1A) and net time and gross times (FIG. 1B) of the programs within the call hierarchy. Referring to FIG. 1A, program A first calls program B, and next calls program C. In this call hierarchy, program A is the calling program that is at a higher level in the hierarchy and programs B and C are called programs that are at a lower level in the hierarchy. As used herein, ‘net time’ signifies time spent in a program, method, function or the like that cannot be split further into sub calls, sub functions, sub programs, etc. it typically includes all basic operations such as concatenating strings or elementary mathematical operations, and ‘gross time’ signifies the net time of a program, call, method, function or alike plus the sum of all gross times of its child calls, programs, methods, functions and so on. In this example, program A has a net time of 1+1+5=7 seconds; program B has a net time of 2 seconds; program C has a net time of 3 seconds. Called programs B and C occur in the course of the running of program A. The run times of programs B and C are added to the net time of Program A to determine the gross time of Program A, which is 7+2+3=12 in this example.
FIG. 2 is an illustrative computer generated user interface display showing call hierarchy relationships among a chronological sequence of call events within a trace log file. Call events near the top of the list occur before call events lower on the list. The display shows gross times and net times for calls, call levels and text indicative of the call events. Each row in the display represents a different call log record. The call text in each row identifies the event to one skilled in the art. Call level 0 is the highest call level, followed in order by call level 1, call level 2, etc. The, display includes both time sequence information through the chronological ordering of call events and call hierarchy information through the call hierarchy relationships among calls.
Detailed text traces of object orientated coded computer program based applications are very long and difficult to read since they often include hundreds of thousands or millions of call event log entries. Using a text-only call trace to analyze an application, therefore, can be time consuming or perhaps only feasible following some aggregation of log entries. Aggregation, however, poses a risk of losing important information especially since object orientated frameworks can be made up of hundreds of different parts and can effectively not be easily aggregated. Efficient software product optimizations during software development often rely upon quick access to detailed and accurate information on response times, for example, and may require insight into large blocks of atomic log entries ranging from a few hundred to tens of thousands entries to be handled simultaneously. While software tools are known that optimize single calls, there has been a need for an improvement in approaches to analysis of complex call structures that are typical within complex object frameworks and call hierarchies.